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Abst ract 

With the development of high level languages for new canputer architectures cones the 
need for appropriate debugging tods as veil. One mthodfor meting this needuoddbe 
to develcp, framscratch, asythdic debugger wththe introduction of eachnewlanguage 
inplemntalicm for ary given architecture. This, however, seem to reqdre unnecessary 
duplication of effort anting developers. Gmpilaticn techndogy has alleviated scm da 
plication of effort in the development of ccmpilers. (hn sinnlar ideas aid in the efficient 
development of syrhdic debuggers as veil? 

Mygen explores the possibility of mki ng debugger development efEient hy influencing 
the language and architecture development processes. Mygen is a “debugger generation 
systeip” built upon the i dea that syrhdic debuggers can be dividedintothree ccmponents: 
a set d source language interface routines, a set of machine architecture interface routines, 
and a language-independent and architecture-independent debugger skeleton Mygen then 
expldts this nodularity: First, Mygen precisely defines as 'veil as houses the language- 
independent and architecture-independent debugger skeleton Second, Mygen defines the 
protocd for interface interactianammg source language developers, machine architecture 
developers, and the general-purpose debugger skeleton Enally, Mygen provi des afram- 
verk in which the resident debugger skeleton is automatically developed into a stand alone 
symbolic debugger; the resulting debugger is tailoredtothe specific provisions of aparticular 
language group and a particular architecture groupx 
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Chapter 1 

Int r oduct i on 


Kcent years have seenasurge of newconputer architectures as industry andacadeiia work 
to devel op faster processi ng pover. IMh the predanhnance of hi gh 1 evel programing over 
rnchine-level programing as veil, the needfor debugging tools that use source language 
nanas andnotations has increased 1 Mch effort has been gjvento automting the phases 
of ccopiler wi ting in order to si nplify high level language inpl enadt at ion for these new 
architectures. Siilar efforts at autonaticn have not, unfortunately, been given to the 
production of debuggers. 

TM s lack of autonati min debugger product icn can prove expensi ve intermof engineer¬ 
ing hours, and thus mnetary costs, reqtd red for devel opmnt. Ehrly oninthe developmnt 
of an experi rental conputer syst erg a low level debugger is needed to evaluate whether the 
systems working correctly. ^fter the newconputer systems running, eachnewhighlevel 
language writtenfor the systemreqiires a corresponding high level debugger because users 
want to debug interna of the synbds and constructs of the source language. Qk nathod 
for meting these debugging needs would be to develop fromscratcha new debugger for 
each new architecture and for each new language inpienanted for a given architecture. 
ISfortunately, writing debuggers is not only tedous hut also tim censuring. 

lr The terms “high-level debugging,” “source-level debugging,” and “synbolic debugging” are used inter¬ 
changeably to man debugging of program in term of their source-level nanus and constructs. 
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Asinhlar proliemcanfranted carpi 1 er developers about fifteen years ago. Gmpilatian 
technology has since then focused on reducing duplication of effort for various phases of 
compiler iiplenantaticnvithconsiderable success. Mst notably, parser generators [Jcth75, 

MRT9, A>bB6, ET88], such as yacc[ Jch.75], and scanner generators, such as 1 ex( 76TS6, 

ET88], have essenti ally elinhnatedthe nanual creation of parsers andscarmers, respectively, 
less knovmbut also inportant have been efforts at automating the development of code 
generators [OB’S, EN79, Br82, UG82] and even enti re cap 1 er s [ UK +82, lbs 82, Tf90, 

Sto77, Sch88]. Mygen explores the possibility of applying sinnlar ideas of automation to 
debugger development. 


1.1 Project Overview 


His thesis explores a novel approach to providing source- level debugging support through 
the development of a “debugger generation system” In general, an all-purpose debugger 
generation systemnnght be a tod that takes as input a source language description and a 
nachine architecture description, 2 and produces as output a fully functional, standalone, 
language-dependent debugger for the specified architecture. Egure 1-1 depicts suchasys- 
tem 

Adebugger produced by such a generation systemconsists of a cere debugger skeleton 
(SHL) provided by the generator, a source language interface (SE) created by the gener¬ 
ator fremthe source language input, and a nachine architecture interface (]\M) created 
by the generator fromthe nachine architecture input. Egure 1-2 depicts the cotpanents 
of such a generated debugger. 

The debugger generation systemdesigned in this project is called Mygen 3 Mygen 

differs fremthe described all-purpose generation systemin term of vhat infornaticnis 
conveyed frcmeach of the source language and nachine architecture developers to the 


2 Details about the term “source language” and “mchine architecture” can be found in Section 4. 2. 
3 lhe nan® “Maygen” originatedfromanini ti al project goal of generating various synbolic debuggers for 
one specific target architecture, the Myfly[Ehv92]. The project later evolved to enconpass various target 
architectures as well, though the nan® Mygen reroined. 
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generation system In the all-purpose systeip input consists of source language and target 
architecture descriptions that are then used by the generator to autonatically create the 
needed interface routines. In the Mygen systeip the naxinal set of routines catprising 
eachinterface is fully specified by Mygento the users of the generaticn system^ the input 
frcothe users contains infcrnationthat conveys to MygenvWchof the defined interface 
routines are available. Qice the available interface routines are knovn, the Mygensystem 
deterihnes vbat additional carpanedts (parts of the SUL) are necessary to provide overall 
debugger functionality as veil as to promote the smothinteracticnaf the tvo interfaces 
described above. The Mygensystenframawrknaintains the debugger skeleton, interprets 
the inputs, and perform the necessary information processing to create a standalone, 
language-dependent and architecture-dependent debugger. 

Egure 1-3 depicts the interrelationship among users of the Mygensystem Mygen 
users can be classified into one of tw> groups. “Ease I” users wrk wth the Mygen 
systemat debugger generationtim, vhile “Ease II” users wrk vith generated debuggers 
at debugger runtime, 

Aprototype of the Mygen systemhas been developed and tw> test sets have been run 
to demonstrate the viability of such a system The test sets include a declarative Rdog- 
like source language running onatarget virtual machine enalatcr and an imperative source 
language running ana target parallel, massage-passing distributedmnory architecture. 

1.2 Thesis Organization 

The remainder of this thesis describes the advantages and disadvantages of related wrk, 
explains vby the Mygen gener at ed debugger is a more feasible approach, and presents the 
design, implementation, evaluation, and achievements of the Mygensystem 

Chapter 2 begins by briefly examining previous research efforts at providing debugging 
support for mltipie languages. 

Chapter 3 presents the features of the canonical Mygen debugger in conparison and 
in contrast to existing debuggers. 
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Egure 1-3: I nterrelati onshi p Amo n g Mayg e n Us ers 
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Chapter 4 then describes the Mygen systemdesign, induing the source language and 
incline architecture interface protocols, the core debugger skeleton, and the generation 
franawork used to create debuggers. 

Chapter 5 elaborates upon the prototype of the Mygen systemthat was developed, as 
well as provides scm of the nsre interestingiiplenantaticriissues invdved. 

Chapter 6 then discusses the test cases used to evaluate both the capabilities and the 
effectiveness of the generatiansystemprototype. 

Enally, Chapter 7 sunnnrizes the Mygen project, presents the author’s conclusions, 
and speculates upon possible directions for further researchin the area of debugger gener¬ 
ation 



Ch a p t e r 2 

Re 1 at e d Wor k 


The idea of debugger generation, althoughno such systems knovnto exist or toever have 
been desi gned, was proposed by Johns on[ Joh78] inl978. \Kle Johnson’s own focus was on 
providing andtilingual tod for debugging, he ccnnantedthat a debugger generati an sys- 
temcod d possi hi y be an al ternati ve approach to provi d ng source-1 evel debuggi ng support 
for ndtiple languages. 

Ebspite the lack of previous work on debugger generation, two related areas of research 
have provided scm insight far the Mygenproject. Specifically, the areas of ndtilingual 
debugging and language-independent debugging also try to provide debugging support far 
ndtiple languages. 

2. 1 Mil t i 1 i ngual Etebuggi ng 

MLtilingual debugging is a debugging style that perimts the debugging of saftvare in which 
canpanents have been written in rare than cue source languagef Joh82]. MLtilingual 
debugging is useful to consider because of scna issues that are sinhlar to those of debugger 
generation Specifically, the needto distinguishbetweenlanguage-dependent andlanguage- 
independent canpanents of debuggers pertains to both 

Jk> exanples of mltilingual debuggers are \SXEEEKfRa83] and SWIf Gr83]. 
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\SXTEBLGis the 11 Rbugger develcpedat Bgital Bpuipnant Grpxration Er a 

particular set of supported source languages, MKHHJGunderstands: howsynhid nanas 
are ccaposedinthe language, howlanguage egressions are interpreted, howand viien type 
conversions are done in the language, howvalues in the language are displayed, and how 
the language scope rules wrk. AthoughMSOlhUGunderstands this information for a 
defined set of languages, it operates according to the rules of only cue language at a tim. 
\ffin0Gsupports the fdloving languages: assembly, Ertran, Biss, Ifesic, G)bd, 
Ihscal, and Hyl. 

SWTis a source-level debugger developed by Btta General Grpxration SWT 
supports five highrlevel languages, each of vhich conform to an agreed upon “Gram 
Gipler Gaponent Mthoddogy. ” His methodology defines a cannon intermdiate 
language, procedure-cal ling sequence, andlanguage runtim envircnnant that nnst be f al¬ 
loyed by each d the supported languages. Hie languages understood by SWT are: Q 
G)bd, Ertran 77, Ihscal, and Hyl. 

2. 2 Language-i ndependent Etebuggi ng 

Snnlar tothe ideaof mltilingual debuggingis language-independent debugging. language- 
independent debugging refers to debugging techniques that are independent of ary cne 
particdar source languagef Joh82]. A debugging systemthat has dealt specifically vith 
the issue of language-independence is the B5IE systenfJoh77]. Johnson explains that 
a separate <H)ugg,vg language right be desirable. Hie debugging language created for 
the B5IE systerp called Bspel[ Joh81], is designed to aid connnnication between an 
interactive user and a runtim, symbolic debugging system 

2. 3 .Advantages and EL sadvantages 

Indeed, these previous system present approaches to debugging that appear to accomo¬ 
date ml tipie languages. Such accomodati on leads to improved econony of irplemnta- 
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tianas veil as increased ease in product nairtenance. In addition, these system offer a 
certain anaunt of functional consistency to the debugger user. 

ISfortunately, these system have several short carings. Erst, they are unable to handle 
the peculiarities of ary specific language; there is no extensionmchanismwth vhich to 
cater to the needs of a given particular language. Second, the languages supported by each 
of the ml ti lingual debuggers are specified beforehand; to handle another language wjuld 
manhaving to rewit e the debugger itself. These system are liritedto debugging not just 
a pre-defined set of languages, hut mreover, only a pre-defined set of senantically sinhlar 
languages. 

Afurther fault lies inthe language-independent debugging systemas veil. Auser rust 
first learn a carpietely separate language, the debugging language, before even being able 
to start debugging a program Qice debugging can actually proceed, the user then needs 
to wrry about the possibility of faulty dsfargenp pKgrams in addition to faulty source 
program. 

Alnittedly, ml ti lingual and language-independent debugging techniques offer sera 
gains over single-language debuggers. Nevertheless, the deficiencies in these debugging 
techniques are considerable. 



Ch a p t e r 3 

Canonical Gener at ed Debugger 


The Mygen debugger tries to Maintain the desirable features of nnlti lingual andlanguage- 
independent debuggers vihile also trying to inprove upon their short carings. His chapter 
begins by describing the features of the canonical Mygengenerated debugger, proceeds to 
explainthe mti vat ion behind the chosen desi gn, and then demnstrates howthis designis 
able to offer rare than ndtilingual and language-independent debuggers. 

3. 1 Qrervi ew 

Hie canonical Mygen debugger generally resenhles atypical single-language source-level 
debugger for a carp led language inthat it offers the “trad ti anal’’functionality wthv4ich 
users are accustcmdto debugging program. Hie Mygen debugger debugs carp led code 
that has not been optinhxed. It is also expected that the user starts up the Mygen de¬ 
bugger and then runs a programunder debugger control. Hie naxinal set of fundanantal 
debugging facilities that are supported 1 by a Mygen debugger include: starting, stopping, 
single-stepping, and cantiruing an execution; loading a fie; resetting the nachine; setting, 
clearing, and listing nachine-level as veil as source-level breakpoints; activating and sus- 

x Each of the supported facilities is onl y avail ali e upon sati sf acti on of specific condi ti ons. See Chapter 4 
for det ai 1 s. 
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Bie 3.1: Canoni cal Maygen Debugger Functi onali ty 


Start execution 
Stop execution 
Ghnt i nue executi on 

Single-step execution (fdlowng calls) 
Single-step execution (not fdlowng calls) 
loadable 
Kset the mchine 

Set, clear, list mchine-level breakpdnts 

Set, clear, list source-level breakpoints 

Ativate breakpdnts 

Suspend breakpoints 

Bsplayandset variable values 

Bsplayregister values 

Tace and untrace variables 

Tace and untrace procedures 

list traced variables 

list traced p’ocedures 

list user prograniabds andsyiiids 

Showcurrent source line 

Bint informlianabaut debugger status 

Bsplay list d debugger connands 

bfepeat pevious connand 

Quit Bbugger 

Gmnant (ignored) 


pending breakpdnts; dsplaying and setting variable values andregister values; tracing and 
untracing variables and procedures; listing traced variables and procedures; indicating the 
current source line; dsplaying a list of debugger connands wth help infer nation; repeat¬ 
ing the previous connand; qdtting the debugging session; and addng a cannant. The 
Mygen debugger functionality is sunnari zed i n r BJi e 3.1. 

Ehch connand’s avail ability depends uponits semdtic correctness inthe context of the 
particular source language or mchine architecture involved, as veil as upon the support 
providedbyboththe source language andthe mchine architecture developers. Rr exanple, 
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a debugger user shouldnot be abletoset logic variables inltdog; thus, the cconandtoset 
the value of avariableis not mde available inagereratedlbclog debugger. In this nanner, 
each generated debugger is tailored specifically to the parti cdar language and architecture 
in question 

In addition to the fundanantal debugging facilities, the Mygen debugger also has a 
mchanismfor incorporating extension cconands that are thenfdly available to the de¬ 
bugger user. Ibr exanple, the option to choose vbether an execution vill proceed in a 
breadthrfirst nanner or adept!* first nanner is not providedby the canonical Mygen de¬ 
bugger; hovevar, this right be a desirable cconandto have inalbdog debugger. Alholog 
systemdeveloper, then, can specify this option as an extension connand to the Mygen 
systeip vhich vill then add it to the set d connands available in the generated ltdog 
debugger. 

Efltensi on connands can be specified and provi ded by the source language developer, 
the nachine architecture developer, or both Efltension connands are of tw> general fla¬ 
vors. “Independent” extension cconands are self-contained in that their functionality does 
not depend upon ary routines that right not be available, e. g., fromeither the source Ian 
guage interface routine set or the nachine architecture interface routine set. ‘Tipendent” 
extension connands, on the other hand, are not self-contained in that their functionality, 
and thus their availability to the debugger user, depends upon at least cue of the routines 
fromeither the source language interface routine set or the nachine architecture interface 
routine set. 2 

Enally, the canonical Mygen debugger understands that not all nachines are uniproces¬ 
sors; the Mygen debugger understands that anachine nay have mre than cue processing 
node. Insuchcases, the Mygendebugger operates onasinglenode at atim. The debugger 
user has the ability to deternhne the total nurher of processing nodes present, deternhne 

2 Ether type of extensi on conmnd—independent or dependent -ean use rout i nes expli ci tl y provi ded by 
the debugger skeleton if desired. (See Chapter 4 for details.) Since the availability of an extensi on conrand 
does not hinge upon the avail ability of routines provi ded by the debugger skel et on (because the latter are 
al ways aval 1 abl e), debugger skel eton routi nes do not pi ay a rol e i n the cl assi ficati on of extensi on connands 
into one of the two categories. 
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Hie 3.2: Ad d i ti onal Maygen Debugger Functi onali ty for Multi proces 


BspLay nuther of nodes present and available 

Showcurrent node 

Swt ch to a di flerent node 

Change nuther of nodes available 


the nuther of nodes available, deternhne which node is being debugged, swtchfrcmthe 
current node being debugged to a different node, and change the nuther of nodes available. 
Mygen’s default node of execution fcr ndti processors is that vhichis provided by the 
nachi ne archi t ecture devel oper. Kbl e 3.2 sunnari zes the add ti cnal debugger functi anal i ty 
provided by Mygenfor ndti processor architectures. 

3. 2 Etesi gn 

3.2. 1 Etebuggi ng Unopt i ni zed Conpi 1 ed Code 

The canonical Mygen debugger was developed to work on uroptiiized, conpi led code 
rather thanonoptiniizedar interpreted code. Athoughusing aninterpreter as the base of a 
debugger tight be beneficial because of howwell it supports interactive debugging[Mk91], 
the approach is tnre conplicated In addtion to a debugger skeleton, the generation 
systemwodd need to naintain an interpreter skeleton as well. His interpreter skele¬ 
ton either would need to interpret a broad class of source languages, which is currently 
i nfeasi hi e[ Jcth77], ar wod d need to be devel oped by the generati on system nto a 1 anguage- 
dependent, architecture-dependent interpreter. The generati on of such an interpreter right 
itself be an interesting research prod eipbd is tangential to the issue of debugger genera¬ 
tion 

Erthernore, Tdsi[To82] pdnts od that interpreted code nay run differently than 
compiled code; thus, a debugger based upon aninterpreter naynot illirinate the problem 
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area of the source code. In addition, a debugger based upon an interpreter right suffer 
fromsi gni ficantl y decreased executi on speed[ BW5]. 

Iikewse, the issue of debugging cpt irixed code is also tangential to the pri nary concern 
of howtoautanaticallycreate asyrhdic debugger. 3 Thus, the canonical Mygendebugger 

expects that the code a user loads and therefore wants to debug is uncptirixed Qice such 
code has been deter lined to be correct, then the user can explore perfornance issues. 

3. 2. 2 Provi di ng Tai 1 ored, Tbadi ti onal Functi onal i ty 

The canonical Mygendebugger offers a variety of trad ti onal debugging connands to the 
user. Such a desi gn was chosen not only because users are mre accustcmdto this mthod 
of debugging and thus can have less startup tim learning howto use a Mygen debugger, 
hut also because users wouldbe provi dedvith the essentials of aruntimdebuggingsysterp 
which are the ability to set breakpoints and exarine values vithin the programbeing 
debuggecf &o79, Joh81]. 

Sana trad ti onal debugging connands, such as starting an executi on, rate sense for 
essentially all languages. The relevance of scm other connands, however, are not nec¬ 
essarily innadately apparent. Er exarple, setting a breakpdnt nates perfect sense in 
a language such as Cor Ihscal; hut, what does it naan to set a breakpdnt in Ifdog? 

It right, for exarple, naan the ability to temporarily step execution at ary of the four 
ports of the ml ti parted box nodel far Ifdog executi an[ S\SD]. Aiother exarple is the 
tracing of variables. Ibis right mke good sense inanirperaiite language, hut what does 
it man in a declarative one? Ai exarple of howthe tracing of variables coddbe used 
in a declarative language is to fdlowclauses that natch (are true) for a particular search 
In cases such as the two described, it is left up to the language developer or architecture 
developer to decide in what narmer each supported trad ti onal debugging comandcanbe 
best expldtedfor debugging of the gi venlanguage on the gi ven architecture. 

3 See Section 7. 2. 2 for mire details. 
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3. 2. 3 Supporti ng Extensi on Cbirminds 

Akittedly, not all of the traditional debugging cannands are necessarily applicable for all 
source languages or all rnchine architectures. Kr this reason, the Mygendebugger right 
only provide a subset of the trad ti anal cconands, depending an the specific language and 
architecture in question That is, the Mygendebugger is specifically designedtobe capable 
of having a cconandset tailored to the target language and architecture. 

This tailoring of the Mygen debugger’s connandset goes beyond sinpily deleting ir¬ 
relevant or inapplicable tradtianal debugging cannands. Sucha systemwouldbe not only 
too limiting far the extrendy unconventional target language and/or architecture, hut also 
not good enough far a rare conventional hut slightly different target language and/or ar¬ 
chitecture. Axordngly, the Mygen debugger is designed to support extensi an cannands. 

The extension cannands enable language and architecture developers to extend the basic 
connandset of a Mygen debugger to include ary add ti anally desired functionality that 
is potentially highly-specific far that particular language or architecture. 

3. 2. 4 Supporti ng IViil ti processors 

Athough the target architecture far Mygen right be a parallel one, the focus of this 
proj ect i s on devel opi ng a method f or gpnerdirg (HMgsrs rather than on deterrini ng the 
best vay to irylemt apsdld ckbuffr-. Thus, Mygen debuggers have been designed to 
deal only wth si rpl emotions of parallelism^ such as knowing about the existence of naltiple 
processing nodes. AMygen debugger operates on one processing node at a tim and can 
swtchframane node to another upon the user’s request. These capabilities allowfar rare 
meaningful debugging car anal tipnrocessor than possible from debugger wthabsdutelyno 
knowledge of ml ti pie nodes. Mygen generated debuggers do not, however, address mare 
coplex parailelismissues, such as the nanitcring of interprocess connnnicatian Such 
issues, alt hough potentially beneficial, wod d tend to detract frcmthe primary concern of 
the project. 
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3.3 .Advantages 

The rare obvious advantages of using Mygendebuggers over tradtianal, single-language 
debuggers are sinnlar to the advantages attributed to the use of ndtilingual or language- 
independent debugging techniques. Erst, Mygen debuggers still present a certain degree 
of functional consistency to the debugger user, resulting in less learning overhead. Second, 
Mygen debuggers are cheap to buildsince they require little wrk on the part of language 
developers and architecture developers conpared to the effort needed to create debuggers 
framscralch. Enally, naintenance is simplified because the driving engine of the debugger 
is sinnlar fromane Mygen debugger to the next. 

Wle Mygen debuggers share the advantages of nalti lingual and language-independent 
debugging system over traditional, single-language debuggers, Mygen debuggers addi¬ 
tionally canpens ale for the deficiencies inherent in nalti lingual and language-independent 
system. Mygen debuggers are flexible; they can be tailored to the specific needs and 
peculiarities of different languages and architectures. This flexibility corns in part from 
the selective availability of the supported debugging routines. Mre inportantly, though, 
this flexibility corns fromthe systeihs allovance of and support for extension cconands. 

These features taken together result in a systemcapable of handling semdtically differ¬ 
ent languages. Eirthernare, Mygen debuggers can be generated for mre than just a 
pre-defined, limtedset of languages. 

Hiwis it that the Mygen debugger can be so flexible? The ansver lies inthe fact that 
it is a generated debugger, that it is generated accordng to the specifics of each particular 
language and each particular architecture. This is nade possible through the Mygen 
generali on system 



Ch a p t e r 4 

Gene rat i on Syst em Etes i gn 

4. 1 Qrervi ew 

lie Mygen systemconsists of three mjcr conpanents: a set of interface protocols, a 

debugger skeleton, and a generalionframwrk The protocols specify the exact nature of 

the interface routines that promte s mot hccomi cat ion between the debugger skeleton 

and the rest of the programhng envirmmnt. 1 The routines that are available for a given 

debugger to be generated are conveyed by my of input files to the generati on framwrk. 

The generati on framwrk, housing the debugger skeleton, processes the input data and 
produces a stand alone, language-dependent and architecture-dependent debugger. 

Egure 41 portrays the canponents of the Mygen systemandhowt hey are interrelated, 
vhile Egure 42 show the pieces of a Mygen generated debugger. 

The Mygen systemms designed in this mrmer in order to have the capability of 
producing a debugger that is flexible, in term of handling very different inputs, yet prac¬ 
tical, in term of providing large savings to language and architecture developers. Since 
iinterpreter-based debuggers have sons intrinsic problem, the debugging of corpledcode 
ms chosenas the basis for Mygen. The decision to have a generati on systemat all evolved 

lr Ihe “rest of the programing envi ronnsnt” refers to the “source language” and “mchine architecture.” 
These are expl ai ned i n detail i n Secti on 4. 2. 
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E gure A 2: The Components of a Maygen Generated Debugger 

fronihe knowledge that im generated debuggers, suchas mi ti lingual debuggers, lackthe 
flexibility needed to support an arbi trary nuriier of language system as well as to handle 
semdtically different language system. Qi the one hand, the generation aspect, tailoring 
ability, andextensionmchanisimf the Mygensystemnake cananical Mygendebuggers 
flexible. Qithe other hand, the core debugger skeletonalang wththe automatic processing 
of it into a generated debugger mke canani cal Mygen debuggers practical. 

Ai al ter nat i ve mt hod that was consideredfar achievingthe dual goals of flexibility and 
practicality was to add debugging constructs to a source fie in a preprocessing-type step 
Eeprocessors have the advantage that the carpler of the source language to be debugged 
need not be nadif]ecl[BM5]. This mthod, however, seemdtobe extrenaly limting in 
term of what debugging capabilities a debugger user would have, as well as in term of 
what languages and system could actually be handled effectively. 
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4.2 Interface Protocols 

Aiinportant aspect of developing the Mygen system! s deciding upon the interaction of 

the Mygen debugger wththe rest of the world. Sana programing languages enplqythe 

notion of anabstract nachine, or virtual nachine, vith which to serve conceptual 2 and/or 

iipLemntational 3 purposes. ISfenthis is the case, the high level aspects of the abstraction 

could be exploited for the purposes of debugging. Ai exarple is the nodfication of the 

ports of the Balog boxnadel to support debugging[S\®0]. 

Gmventicmal languages such as Cand Ertran do not really have abstract nachines 
vith which to visualize their execution Er exarple, in a Uix systenjrNJSl], an object 
fie produced by the Ccorpler executes as just another process running under the liix 
operating system Ghnceptually, cue right visualize that process having a certain anount of 
mmry allocated to it andhave auction of data and instructions residing in that mmry, 
as veil as a‘location counter’’that indi cates the current instructicmbeing executed. Gearly, 
suchanantal nadel of programexecuti cm i s down near the level of the operating system 
and nachine architecture on which the process is running. 

The Mygen systemadopts an internadiate position tovard debuggers that atterpts 
to take advantage of higher levels of abstraction when available, hut that can be used for 
lower-level convent i cnal program as well. The Mygensystemseparates the souraepxgxm 
fromthe evduticnmirxnwt. 

Axordingly, the two interfaces to the Mygen debugger are the source programand 
the eval uati cm envi remnant. The interface to the source language is fittingly referred to as 
the Source language Interface (SEI). The interface to the evaluation enviremnant is less 
appropriately ref erred to as the Mchine Achitecture Interface (MI); this interface right 

2 As a conceptual technique, the abstract nachine allows a high level way t o t hi nk about the execution of 
aprogram This capabilityis especi all y useful when the programing language contains non-trivial control 
nschanism such as Prolog’s unification or Snobol ’ s pattern natcher. 

3 A an inplensntation technique, the abstract nachi ne can serve as a specification that describes details 
of aparticular algorithrp such as aunifier or pattern natcher, used to i npl enent thelanguage. In addition, 
the abstract nachine can serve as an i npl ensntati on prototype, as in the Lisp functions Eval and 
which define the conplete Ii sp eval uator injust afewlines of lisp code. 
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enconpass not only the mchine architecture, hut also a runtim systen^ an operating 
systen^ an abstract rnchine, or a cariinaticn. 

The interface protocols specify the exact nature of the routines that are used by the 
core debugger to interact wth the source programand the architecture. 4 Ehch interface 

protocol can be thought of as the set of routines that conpri se the interaction between the 
core debugger and source programmer between the core debugger and rnchine architecture. 

The Source language Interface routines are provided by a language developer, vhile the 
Mchine Achitecture Interface routines are providedby a systemdeveloper. 

Ehchi interface consists of appraximtelyfifteenroutines; these translate to the supported 
functionality of a generated debugger. There exists anhriml subset of routines that are 
required of the Source language Interface and of the Mchine Achitecture Interface in 
order for a wrking debugger to be generated Whthe provision of this nhiinal subset, 

Mygen can autonatically create alowlevel debugger. Whthe provision of increasingly 
mre Source language Interface and Mchine Achitecture Interface routines, Mygen can 
create syrhdic debuggers wth increasingly larger amounts of functionality. These sets of 
interface routines are experinantally derived 

Uhle 4.1 lists the routines constituting the Source language Interface as specified by 
the current Mygen design Similarly, Uhle 4.2 lists the routines contained in the Mchine 
Achitecture Interface as specified by the current Mygen design 

The interface protocols not only specify the routines that should be provided, hut also 
the farnat invWch such infarnati on is conveyed to the generati an framwrk. The input 
to the generati on framwrk consists of twitext files, one for infarnati on about the Source 
language Interface and the other for infarnati on about the Mchine Achitecture Interface. 

The Source language Interface input file contains: ali sting of the Source language Interface 
routines wth specification of vihether or not each is available, the nana of the source 
language, the location and nana of a library containing the Source language Interface 

4 Henceforth, the “mchine architecture” and the “architecture” refer to the evaluation environmmt, 
except when specified otherwise. 
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Hie 4.1: Source Language Interface Ro u t i nes 


Initialize SH 

Mp procedure to object line 
Mp procedure beginning to object line 
Mp procedure ending to object line 
Tace procedure 

Mp source line to object line 
Rad i n synhid s 
Rint labels 
list procedures 
Rint syrhds 

DspLay text of current source line 
lit race procedure 
Rocess initial debugger argumnts 
Rint SR infarnation 


Hie 4.2: Ma chine Ar chi tecture Interface Ro u t i nes 


Initialize Ml 
Is programlceded? 

Install nachine breakpoint 

Ghntinue program 

liinstall nachine breakpoint 

Set nachine breakpoint on a procedure 

Gear nachine breakpoint on a procedure 

Rad in program 

Rint register contents 

Rm program 

Step), fdlowng procedure calls 
Step), not fdlowng procedure calls 
Rset nachine 

Rocess initial debugger argunants 
Rint Ml infcrnaticn 
Change current processing node 
Change nuther of available nodes 
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routines, andinfarmticn about eachextensioncconanddesiredbythe language developer. 

This extension cconand infarnaticn includes the total nuther of extension cconands 
supported by the language developer as veil as details about each extension cconand 
These details include: the nana of the cconand, the declaration used to indicate it is an 
externally defined procedure, the invocaticnof the cconand wt hits argunants, andalist 
of Source language Interface andMchine Achitecture Interface routines upon vhich the 
proper functioning of the extension cconand depends. 5 

Snhlarly, the Mchine Achitecture Interface input fie contains: ali sting of the Mchine 
Achitecture Interface routines wth specification of vhether or not each is available, the 
nana of the architecture or abstract nachine, the location and nana of a library containing 
the Mchine Achitecture Interface routines, and infornation about each extension com 
nanddesiredly the nachine developer. The infornatianfar these extension cannands is 
exactly analogous to that of the extension cannands for the Source language Interface. 

The Mchine Achitecture Interface input file add ti anally contains inf ornati on about how 
nary processing nodes are present as veil as hownary processing nodes are available in 
the target architecture. 

Aiexarple of a Source language Interface input file teiplate, vhichcanbe filled in 
by a language developer, canbe foundin_4>pendx A r^ppendx Bcontains an exarple of 
a Mchine Achitecture Interface input file tenpilate. 

4.3 Etebugger Skeleton 

The debugger skeleton consists of the ccapanents of a syrhdic debugger that have been 
deter rimed to be language-independent and architecture-independent. These ccapanents 
have been grouped together tofornthe core of a debugger, hence debugger skddcn, vhich 
the Mygen systemuses as the backbone vith vhich to create Mygen debuggers. 

The debugger skeleton can be thought of as providngthe glue necessary for coherently 

5 For independent extension conrands, this list vill be enpty. 
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sticking together the interface routines. Mre accurately, the debugger skeleton is several 
files of code, scm of which contribute directiy (unchanged) to the code of a generated 
debugger, and scm of which are either supersets of or inccaplete fragnants of code that 
wll be nadifiedby the generatianframwkintocode that wll then be part of agenerated 
debugger. The final output files include anakefle wth which the user cannake the newly- 
generated debugger fromits source code. 

Mre descriptively, the debugger skeleton consists of debugger cccponents such as the 
debugger user interface, cconand loop driver, and grungy i ni tializat ion and naintenance 
routines, e. g., for keepi ng track of tracing. The debugger user interface can range froma 
single textual interface to annchnsre elaborate graphical user interface. This interface 
need only be written once and then can be used for each subsequent Mygen debugger. 

Ai exarple of a grungy naintenance job is the breakpainting facility; coordinating the 
setting (and checking far duplicates), clearing (and checking far validity), keeping track, 
listing, installing, uninstalling, activating, and suspending of nachine-level and source-level 
breakpoints. 

Ehch debugger cconand supported by the debugger skeletanis afliaiedwth certain 
Source language Interface andMchine Achitecture Interface routines uponwhi chits func¬ 
tionality depends. Agiven, supported debugger cconandis only available if the routines 
uponwhi chit depends are nade available by the language and/or architecture developers. 

Kr exarple, the connand that allows a debugger user to set a breakpoint an a source 
line depends upon cm Mchine Achitecture Interface routine (install nachine breakpoint) 
and cm Source language Interface routine (nap source line to object line). If either of 
these routines is not supported, then the source-level breakpoint setting connand is urr 
available in the subsequently gemrated debugger. The debugger connands supported by 
the debugger skeleton are identical to those previously described in Uhle 3.1. 

A nanticmd previously, a few debugger skeleton routi ms are explicitly provided to 
aid Mygen systemusers. language or architecture developers can freely call these rots 
tines fromwthin either extension connands or Interface routines. The debugger skeleton 
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Bie 4.3: Debugger Skeleton Ro u t i nes Avai lable to Developers 


Install breakpoints 
liinstall breakpoints 

Check whether breakpoint address already exists 
Aid procedure to list of procedure breakpoints 
Knows procedure fromlist of procedure breakpoints 
Aidnachine address to list of nacbine breakpoints 
Know nacbine address fromlist of nachine breakpoints 


routines supported in this narmer are listedin HHe 4.3. 

4.4 Generat i on Framework 

This section describes the overall framwork used by the Mygen systemto create afunc¬ 
tional debugger. This framwrk serves as the driving engine for accepting input inf carna¬ 
tion about the Source language andMchine Achitecture Interfaces, for translating the 
input into which debugger ccnnands wll be available, and for appropriately nidifying 
and appending the debugger skeleton to nake it a standalone debugger. 

The generation framwrk understands the fornat of the input files and thus can read 
andinterpret the infornatianinthe input. The generation framwrk also houses, or rare 
accurately, keeps track of, all the pieces of the debugger skeleton The framwrk knows 
which pieces are to be left intact tobeccmpart of a gemrated debugger as well as which 
need to be either augmntedor chopped and spii ced 

The generation framwork decides, based upon which Source language Interface and 
Mchine Achitecture Interface routines are known to be available, what components wll 
gointothe debugger to be gemrated and howthese canponents shouldbe put together to 
nake awcrMpgurit. The framwarkprocesses the input infarmtionto deternhm which 
debugger cannands wll comprise the ccnnandset of the debugger to be gemrated These 
ccnnandnams are thenimarparatedintothe “help list” avai lable to debugger users, while 
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the code that inpilenants these cconands are incorporated into the source code files that 
conpile into the functional debugger. Enally, the generation framwrk outputs all the 
necessary code files and a mkefile for the newMygen debugger. 

The framwrk i s designed to perform^ gsrmtiontim all of the interpretation and 
processing necessary for a given debugger tobe generated. 1^ per for ring all input interpret¬ 
ing and processing during debugger generation, Mygen debuggers can aroidunnecessary 
runti m i neffii ency. 



Ch a p t e r 5 

Prototype I npl eirent at i on 


The Mygensystemdesignenconpiasses rare than does the prototype that has been i npl e- 
mdtedthus far. This chapter describes the erraramsnt inwhichthe systenwas developed 
and the scope of the prototype, as veil as presents scm of the mre interesting inplemn 
tational details. 

5. 1 Qrervi ew 

The experinadt was carried out using the equipnadt and facilities of Hewlett Rebard 
Iaborataries. A single-p’ocessar workstation H9000/840 running IPIX 7.0, Hewlett 
Rickard’s wersionof was usedfor the dewelopnant of the debugger generationsystem 
The prototype Mygen system! s written in the Clanguage. 

The prototype generationsystemconsists of the Source language Interface andMchine 
Achitecture Interface potocols wth routines defined and input file fornats specified, an 
inplemnted subset of the designed debugger skeleton, and a functianal generati on frana- 
workthat handles the existing debugger skeleton and inputs. 
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5.2 Mygen Debugger Features 

The canonical Mygen debugger of the prototype generation systemsupports mst of the 
functionality supported by that of the designed system These cannands are sunmarized 
in Tble 5.1. The cannands that are not supported in this iipl errant at icn are listed in 
Tble 5.2. Ai addtianal note is that the support for tracing and untracing of procedures 
is currently irpl errant ed as the setting and clearing of breakpoints on procedure nanas. 
Taring of procedures cod d be mde mre elaborate by not caiybreaMngvihen a procedure 
is reached, but al so autonati call yd splaying the values of the procedure’s argunants upon 
irrvocaticrr and di splaying ary return value upon exit. 

A in the design, each debugging canmand’s availability depends upon its senantic 
correctness in the context of the particriar source language or rnchine architecture irr 
vdved, as veil as upon the support provided by both the source language and the rnchine 
architecture developers. 

The prototype canonical Mygen debugger is able to support one of the tw> flavors 
of extension cannands described in Section 3.1. Independent extension cannands are 
currently incorporated in the prototype, vbereas dependent extension cannands are not. 

Enally, the prototype Mygen debugger operates ana single node at atim, but under¬ 
stands that there right be mre than care processor inthe target architecture. Thus, vihen 
the target architecture has naltiple nodes, the generated Mygen debugger allow the user 
to: deteriine the total nutter of nodes present, deteriine howrany nodes are avail able, 
find out vrhichnode is being debugged, svitchbetveennodes, and change the nutter of 
nodes available. This functionality is identical to that designed, vihichis sunmarizedin 
Thle 3.2. 

5.3 Int erf ace Prot ocol s 

The Source language Interface and Mchine Achitecture Interface are irplemnted as 
described in Section 4.2, having the goal of separating the source progranfronthe evalua- 
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'Efcle 5.1: Debugger Functi onali ty Implemented In Prototype 


Start execution 
Stop execution 
Ghnt i nue executi on 

Single-step execution (fdlowng calls) 
Single-step execution (not fdlowng calls) 
loadable 
Ifeset the uadine 

Set, clear, list nachine-level breakpdnts 

Set, clear, list source-level breakpoints 

Atirate breakpdnts 

Suspend breakpoints 

Bsplay register values 

Pace and untrace procedures 

list user prograiriabds andsyiiids 

Showcurrent source line 

Hint infaruationabout debugger status 

Dsplaylist d debugger connands 

Ifepeat previous connand 

Qdt Bbqgger 

Gkinant (ignored) 


'Hie 5.2: Debugger Functi onali ty No t Implemented i n Prototype 


Bsplayandset variable values 
Tace and untrace variables 
list traced variables 
list traced procedures 
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ti on envi remnant. The specified routines conpri sing the Source language Interface are the 
sana as those listed in'Hie 4.1; likewse, the specified routines conpri sing the Mchine 
Achitecture Interface are the sana as those enunaratedin Hie 4.2. 

The input fie fornats, which the Mygenprototype uses, are identical to those pre¬ 
scribed by the interface protocol design of Section 4.2. The sarple Source language In¬ 
terface input fie tenplate locatedinJ^penix Ais the actual input fie tenplate used for 
the prototype’s language test cases. Snhlarly, the sanpile Mchine Achitecture Interface 
input fie tenplate located in J^penix Bis the actual input fie tenplate used for the 
prototype’s architecture test cases. 

5.4 Debugger Skeleton 

The prototype debugger skeleton consists of conpanents of a syrhdic debugger that are 
language-independent and architecture-independent, as designed H>wew, the prototype 
debugger skeleton does not enconpass as nodi basic supported functionality as does the 
designed debugger skeleton Aso, the debugger user interface is a purely textual one. 

The cannand loop diver is based upon a Clanguage switch statenant that swtches 
on the interactive user’s typed cannand This inplenantaticn was chosen for relative 
effiiency in carrying out the desired cannand and for ease in tailoring the appropriate 
code files to the inputs. 

The debugger skeleton consists of five files that contribute unchanged to a generated 
debugger’s source code and sixties that are nod fied into files that are then d recti y part 
of a generated debugger’s source code. The files that cantrihute unchanged contain source 
code files that inplenant breakpdnts, essential debugger initializations and diver routines, 
and input/out put routines. These files also include header files that list Source language 
Interface, Mchine Achitecture Interface, and debugger skeletonroutines. 

The files that need to be nodfied before becanhng part of a generated debugger are 
the nakede, “cases” fie, “filler” fie, extension cannand fie, “tinscellaneous” fie, and 
“debugger help list” fie. The “cases” fie is a superset of the code needed to decide what 
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to perfarmfor each cconand the prerequisite routines are available for a given 

debugger cannand, that comnandwll be associated vrth code that perform the actual 
cannand; vhen the prerequisite routines are not available, hovever, that cannand vi 11 
be associated wth code that relays to the user the unavailability of the invoked cannand. 

In addtion, each cannandis accordingly added or not added to the debugger help list in 
the “debugger help list” fie. Thus, vhenauser calls upahelplist of debugger cannands, 
those cannands that are not available, due to lack of suffiient support frcmeither the 
language or architecture developer, wll not be indudedinthelist. lie “filler” fie is created 
by Mygento account for all of the Source language Interface and Mchine Achitecture 
Interface routines that are not providedas inputs. Mygencreates “filer”routines to satisfy 
the cotpler’s checks, knowing that these dump routines vill not actually be called The 
extension cannand fie is created by Mygento hande the calling of appropri ate extension 
cannands upon a user’s invocation of such cannands. Enally, the “miscellaneous” fie is 
created by Mygen to hdd tw> architecture-dependent definitions as veil as routines for 
printing infarnatianupon debugger startup and exit. 

5.5 Generat i on Etanework 

The prototype generationframwrkis as described in Section 4.4. This generationfram- 
wrk understands the input fie fcroats, reads and interprets the input files, accordingly 
perform the actual nadfyingaf the debugger skeleton files described in the previous sec¬ 
tion, and outputs all necessary source code to create a new debugger. 



Ch a p t e r 6 

Re s ul t s 


His chapter discusses the test cases used to evaluate the prototype generalionsysten^ and 
hence the Mygensystemdesignitself. 

6. 1 Qrervi ew 

The goal for choosing the test cases vas to select donains that are quite different in order 

to showthe flexibility that Mygenhas in conparisan to existing system fcr providing 

debugging suppcrt to ndtipie programing emironnarts. Ehchtest set 1 is conprisedof 

a source language that ccnform to the Source language Interface protocol (in term of 

interface routines and Mygeninput fie), and a nachine architecture that conform to the 

Mchine Achitecture Interface protocol (in term of interface routines and Mygeninput 

file). 

Tk>suchtest sets have been run through the Mygensystem The tw> source languages 
and their evaluationenvironnants are: a declarative language, CBi* running on the (M 
virtual mchine, andaninperalivelanguage, Q running onthe MyflypBrallel architecture. 

I|r generating a syrhdic debugger for both a declarative language and an inperalive 
language, Mygen demnstrates its ability to handle semnti cally-different languages. 

1 A“test set” consists of both a source language “test case” and a mchine architecture “test case.” 
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'Hie 6.1: SLI Routi nes Supported By OPAL 


Initialize SB 

Mp procedure to object line 

Mp procedure beginri ng to obj ect line 

Rad i n synhd s 

Bint labels 

Bint syrhds 

Bint SB infarnation 

Bocess initial debugger argunaits 


6. 2 Tfest Cases 
6. 2. 1 OPAL and CM 

CBij the Qegon Rrallel logic language, is a Balog-like language developed at the 
liiversity of Gegan[Ghn90, Ghn91, Gm92]. CBA is based an the AtyCR Bocess 
Mdel[Kic90], vbichis an abstract nadel for parallel logic program. The AtyCRBo- 
cess Mdel has an operational senantics defined by asynchronous objects that ccmnnuicate 
entirely by mssages. 

(BAprogram are carpi edinto the instruction set of the (BAMcbine, or OM. The 
(Ms a virtual nacbine sinnlar to the Wren abstract nacbinef W83] for standardBdog 
inplenadtations. The difference is that the (Mvirtual nachineis designedfor p’ograna 
that execute accord ng to the AtyCRBocess Mdel onnansharedmnarynnltiproces- 
sors. The version of the (Mvirtual nacbine used for this test set runs on a uniprocessor 
INXwrkstation; it does not expldt A®or CRparallelisirinthis inpilemntatian 

The (BA language test case supports eight out d the fourteen Source language lit 
terface routines specified by the Mygenprototype and provides no extension connands. 

The routines supported by (BA are summarized in Hie 6.1, viile those that are not 
supported are listedin Hie 6.2. 

The CMnrtual nacbine test case supports fifteen out of the seventeenMchine Achi- 
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Hie 6.2: SLI Routi nes Not Supported By OPAL 


Mp procedure ending to object line 
Pace procedure 

Mp> source line to object line 
list procedures 

BspAay text of current source line 
Tit race procedure 


tecture Interface routines specified by the Mygenprototype. Alditianally, the (Mtest 
case provides twelve independent extension connands. 

Hie (Mvirtual nachine supports all of the Mchine Add tecture Interface routines 
except the tw> routines specific to mltiprocessars since the (Miplemntatianis far a 
uriprocessor. Hies 6.3 and 6.4 sunnarize those routines supported and not supported, 
respectively, by the (Mvirtual nachine. 

Hie extension ccnnands provided by the (Mvirtual nachine provide the debugger 
user vith the capabilities to choose betveen: searching for all solutions cr fcr just cne 
solution, perfcrnhngabreadthrfrst or a depthrfirst search, e^cuting in quiet node or not, 
tracing processes or not during execution, tracing instructions or not during execution, and 
displaying registers synbdically or not. Hie extension ccamands also enable the user to 
print sections of object code, sections of the heap being used by the (Mvirtual nachine, 
nassage or process inf Croatian, queue contents, andaprocess tree for the execution Hiese 
additional features are surxnarized in Hie 6.5. Asanple (MMchine Achitecture 
Interface input fie can be found in_4pendix C 

Hie Mygen generation framwrk accepted the input files of the described test set 
and produced a synbdic debugger for (BA running on the (Mvirtual nachine. Hie 
debugger connands supported by the generated (BA debugger are listedinHie 6.6 
Hie (BA Source language Interface input fie and the (MMchine Achitecture 
Interface input fie vere tested to have varying nurhers of interface routines available to 
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mie6.3: MAI Routi nes Supported By OM 


Initialize MI 
Is programl ceded? 

Install nachine breakpdnt 

Ghntinue program 

liinstall nachine breakpdnt 

Set nachine breakpoint on a procedure 

Gear nachine breakpoint on a procedure 

Rad in program 

Bint register contents 

Rm program 

Step, fdlowng procedure calls 

Step, not fdlowng procedure calls 

Ifeset nachine 

Bint MI infornaticn 

Bocess initial debugger argunadts 


'Hie6.4: MAI Routi nes Not Supported By OM 


Change current processing node 
Change nuther d available nodes 
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Bie6.5: MAI Extensi on Commands Provi ded By OM 


Tggle all-solutions 
Tggle breadthr first search 
Tggle quiet rode 
Tggle process trace 
Tggl e i nstructi on trace 
Tggle synhidic register display 
Bint code 
Bint heap 

Bint nassage infornatian 
Bint process infornatian 
Bint queue contents 
Bint process tree 


Mygen. lie supportedfunctimalitycf eachresdting debugger variant ms checked 
to ascertain that the debuggers changed accordingly. These generated GH/ debugger 
variants vere then tested on a suite d GH/program to verify their correctness. 

6. 2. 2 C and IVftyfly 

The language of the second test set is C| the fanhliar, inpuerative language developed by 
Rtchie[H88, H®1]. Cis arelativelylowlevel, general-pjurpxxe programing language. 
Wle Cprovides datatypes and fundamdtal contrd-fbwcanstructians such as looping 
and decision naking for single-threaded control fbvy it does not provide huiIt-in higher- 
level mcharism suchas input/outpjut facilities or operations ancanposite objects suchas 
lists and arrays. 

Grp led C program are processed by the Myfly architecture[Biv92]. The Myfly, 
developed at Hviett Ibckard labor atari es, serves as a back-end processor for a HMett 
Ihckard Series 800 vrrkstation The Myfly is a scalable, general-purpose parallel pro¬ 
cessing architecture; it is a cEstributednanarynachine wthccomicaiioi supported by 
nassage passing. 
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'Hie 6.6: Functi onali ty of the Generated OPAL Debugger 


Pint help infarnatian 

Ifepeal previous cconand 

Ati'vate breakpdnts 

Set breakpoint on object line 

Set procedure breakpoint (trace procedure) 

Ghntinue framhreakpoint or step 

Eblete breakpoint on object line 

Eblete procedure breakpoint (untrace procedure) 

Ifead in coupled user program 

Dsplay general registers 

Hint infarnaticn about debugger status 

list breakpoints 

list user program!abels 

list user programsynhds 

Qdt debugger 

Rm program 

Single step (fdlowcalls) 

Single step (do not fdlowcalls) 

Suspend br eakpd nt s 

Ifeset nacbine to startup state 

Gmnadt (ignored) 

Execute an extensi on ccmand; 

- Tggle all-sduticns 

- Tggle breadthrfirst search 

- Tggle qdet node 

- Tggle process trace 

- Tggle instruction trace 

- Tggle syrhdic register display 

- Hint code 

- Hint heap 

- Hint nassage infornaticn 

- Hint process infornatian 

- Hint queue contents 

- Hint process tree 
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'Hie 6.7: SLI Routi nes Supported By C 


Initialize SB 

Mp source line to object line 
Mp procedure to object line 
Mp procedure beginning to object line 
Mp procedure ending to object line 
list procedures 
Rad i n synhd s 

Bocess initial debugger argumnts 
Bint SB infornalian 


Hie 6.8: SLI Routi nes Not Supported By C 


Tace procedure 
Ihtrace procedure 
Bint labels 
Bint syrhds 

Bspiay text of current source line 


The Clanguage test case supports nine out of the fourteen Source language Interface 
routines specified by the Mygen prototype and provides no extension ccnnands. The 
routines supported by Care sunnarizedin Hie 6.7, \4ile those that are not supported 
are listedinHie 6.8. 

The Myfly architecture test case supports sixteen out of the seventeenMchine Achi- 
tecture Interface routines specified by the Mygenprototype. The Myfly test case supports 
all of the Mchine Achitecture Interface routines except execution stepping that does not 
fdlowprocedure calls. Hies 6.9 and 6.10 sunnarize those routines supported and not 
supported, respectively, hy the Myfly test case. 

Aldi ti anally, the Myflytest case provides three independent extension ccnnands that 
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1516 6.9: MAI Routi nes Supported By Mayfly 


Initialize MI 
Is programl ceded? 

Install nadine breakpdnt 

Ghntinue program 

Step, fdlowng procedure calls 

liinstall nadine breakpoint 

Set nadine breakpdnt on a procedure 

Gear nadine breakpdnt on a procedure 

Rad in program 

Bint register contents 

Rm program 

Ifeset nadine 

Bocess initial debugger argunadts 
Bint MI infarnaticn 
Oenge current processing node 
Oenge nurher of available nodes 


Hie 6.10: MAI Routi ne Not Supported By Mayfly 


Step, not fdlowng procedure calls 


give users the capability to select viidiQUaf the current p’ocessing node to debug. Ekch 
Myfly p’ocessing node has tvoCTO: the Mssage Bocessor (]\JP) and the EcecutionBo- 
cessor (IP). The Myfly ext ensicnccraands provide the debugger user wththe fdlowng 
capabilities: to select the NPcf the current node for debugging, to sdect the EPof the 
current node for debugging, and to deternhne vli ch GUi s the current (being debused) 
GUof a givenMyfly p’ocessing node. These add tianal features are sunnarizedinlble 
6 . 11 . 

The Mygen generation framwrk accepted the input files d the described test set 
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Uhle 6.11: MAI Extensi on Commands Provi ded By Mayfly 


Select MPof current node 
Select EPof current node 
liter line which (HJis current CFU 


and produced a C debugger for the Myfly. The debugger cannands supported by the 
generated Cdebugger are listedinHie 6.12 

The CSource language Interface input fie and the Myfly Mchine Achitecture In¬ 
terface input fie were tested to have varying nutters of interface routines available to 
Mygen. The resulting Cdebugger variants were inspected to ensure that their set of 
supported functionality changed accordingly. A observedfor the CBl/CMtest set, the 
supported functionality of each resulting generated Cdebugger also correctly reflected the 
changed Mygen i nput s. 

Ebe tologistical diffiuLties, 2 the generated Cdebugger variants were “tested” by closely 
watching the cconands atteiptedto be written to the Myfly mritor, the saftvare that 
connects the Myfly architecture vithits front-end workstaticn. Interfacing to this mritor 
is the Myfly 5 s debugger library. Nrnally, any debugger for the Myfly calls basic routines 
frcmthis debugger library. The debugger library routines, which narnally connniicate 
di recti y vi th the Myfly vi a the mri tor progran^ were repl aced duri ng testi ng vi th verbose 
stubs. A teqjtedcannand writes to the mritor frcar^generated Cdebugger variants were 
thencanparedviththe atterptedcanmandwrites of sinhlar debuggirg cconands invoked 
froman existing, tested debugger for the Myfly. 


2 lhe Myfly archi tect ure can onl y be used 1 ocall y because its software currently does not support reraite 
access. Mygen work, however, was conpleted 3000 riles fromthe residence of the Myfly. 
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'Hie 6.12: Functi onali ty of the Generated C De bugger 


Hint help infornatian 

Ifepeal previous cconand 

A:tivate breakpoints 

Set breakpoint on source line 

Set breakpoint on object line 

Set breakpoint at procedure beginning 

Set breakpoint at procedure exit 

Set procedure breakpoint (trace procedure) 

Ghntinue framhreakpoint or step 

Eblete breakpoint on object line 

Eblete breakpoint on source line 

Eblete procedure breakpoint (untrace procedure) 

Kadincanpileduser program 

Dsplay general registers 

Hint infornaticnabout debugger status 

list breakpoints 

list procedures 

list traced procedures 

Qdt debugger 

Rm program 

Single step (fdlowcalls) 

Suspend br eakpd nt s 

Ifeset nacbine to startup state 

Gonadt (ignored) 

Ekecute an extensi on ccmand: 

- Select NPof current node 

- Select EPof current node 

- liter rime vhichCHJis current CFU 
Ekecute andtinode cconand: 

- Giange processing nodes 

- liter line current nurher of nodes 

- liter line current node 



Ch a p t e r 7 

Cbncl us i ons 


Bis chapter sunmarizes the Mygenproject, presents sons conclusicns about debugger 
generation in general and the Mygen approach in specific, and suggests areas for further 
research 


7. 1 Suramry 

The abilitytoprovide debugging support fcr ndti pie languages is aninportant one because 
of today’s denandfor highlevel debuggers to acconpany highlevel languages. 

'Boprevious approaches that vore considered for providing debugging support for nd- 
tipie languages are nnltilingual debugging and language-independent debugging. These 
approaches right be feasible vben the set of languages that the system support are se- 
nadtically very sirilar. Such sirilarity, hovever, my be mre rare in the future and is 
presently nonexistent for parallel languages. Hire there has been a strcpg need to pur¬ 
sue other debugging mthods that are capable of supporting a semdtically di verse set of 
languages. 

Mygen, the debugger generation systemdescribed in this thesis, is precisely such a 
debugging mthod In light of the greater semdtic diversity amongst programing Ian 
guages, this systemis nare feasible than previous approaches to providing debugging sup> 
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part because of its ability to take into account different programing nodels. Aid ti anally, 
generated debuggers exhibit a large degree of functional consistency, thus nhninhzing the 
user’s overhead in learning a new debugging systemfor eachnewlanguage. 

The Mygen systemprovides for “qtdck and easy” creation of language-dependent de¬ 
buggers for the respective target architectures. Suchafeat is nade possible by the systeiis 
inpositicn of interface protocols to be followed by language developers and architecture 
developers, provision of the glue necessary to not only snootily connect the twointerfaces 
but also serve as the core debugging engine, and provi si on of the franawk that perform 
the actual glling of the separate pieces. 

Mygen has been shown to handle botha declarative language and an imperative lart 
guage vith reasonable results. The generated debuggers provided at least the nhninal 
functionality needed for useful debugging vithout nnch add ti anal effort on the part of lanr 
guage and architecture developers. Mreover, the generated debuggers were able to cater 
to the particular needs of eachlanguage and each architecture. Specifically, the generated 
QMj debugger included several ccnnands to provide for debugging features specific to 
Balog-like languages, while the generated Cdebugger included cconands to provide for 
debugging features specific to mltiprocessar architectures. 

Thus, the Mygen debugger generation systemis a viable approach to providng de¬ 
bugging support for naltiple languages, an increasingly inpart ant consi derati on as very 
dfferent languages, such as parallel languages, are created 

7. 2 Fut ure Work 

Because Mygen presents afeasible sdutionfor providng debugging support, it is interest¬ 
ing to speculate upon what drections further research in the area of debugger generation 
right take. 
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Hble 7.1: Future Maygen Wjrk 


Aid ti anal test sets 
Inproved test cases 

IMianced skeleton and add ti anal interface routines 


7. 2. 1 IVftygen Prototype Enhancements 

Several areas call for innadaie inprorenant inthe Mygenprototype. IVfet notablyis the 
need to further explore the saiple space of programing languages and their evaluation 
enviremnants by creating add ti anal test sets. Agoodthirdtest set ihglt be the Ii sp[ M84, 
& 086 ] language along viththe lisp runtina system In addition, the existing test cases 
shouldbe expandedvhere possible inerder toproduce debuggers wthincreasedamurts of 
functionality. Bnally, the existing debugger skeleton could be enhanced to provide a greater 
naxinal anount of supported generated debugger functionality. His enhancenant raid 
nost likely also require the specification of add ti anal interface routines to be provided by 
the language and/or architecture developers. Hie suggested innad ate nodfications to 
the Mygenprototype are sunnarizedin Hlie 7.1. 

7. 2. 2 Rel ated Areas to Expl ore 

His section presents research areas suggested by Mygen rark hut of a nnch broader na¬ 
ture than that presented in the previous section Hiese areas can be grouped into four 
prinary topics: creation of a Rmtina Systemlnterface (ESI); diaraderizdiono .f a larr 
guage, architecture, or runtina systemand the subsequent autonatic generation of the 
respective Interface routines fromeach characterization; debugging of optinhzedcode; and 
true debugging of parallel system. 

Hk dvisionof the “raid” that Mygen debuggers viewis a rather unique cue. A- 
thoughthe separation of a source programfromthat anvhichit runs, its evaluation envi- 
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ranmnt, is a viable approachfor the Mygen debugger, an alternative d vision right be 
to separate the source programfromits runtim systemas veil as fromits architecture. 

His approachnhght provide for a “cleaner” andmre tradtianal d vision; hut, at the sana 
tim, this approach right be unnecessarily carpi ex due to the desire to expldt higher-level 
abstractions vhen available, as described in Section 4.2. 

A mre thought-provoking area to explore is that of characterizing a source language 
in a vay that a generation systemcodd then autonatically create the Source language 
Interface routines defined in the Mygen system Aralogously, the characterizations of 
a nachine architecture and of a runtim systerp as veil as the subsequent generation 
of Mchine Achitecture Interface andRmtim Systemlnterface routines pose interesting 
questions. Akey idea to keep in rind, though, is that alt hough amt hod of characterization 
for these areas coddprove theoreticallyinteresting, it right not be practical inthe context 
of effiient debugger generation Er exarple, language developers right findit mcheasier 
to conformto a set protocd for interface interacti on (i.e., provide defined routines) rather 
than to conformto a “characterizatiarmthod” far describing their language (i.e., provide 
a characterization of their language). 

Athirdideais that perhaps a debugger generation systemcodd be developed that can 
better handle the debugging of optirizedcode. Astart inthat drectionis that generated 
debuggers right be able to support semrtii cal ly-unchargirgoptirizatiars-eptirhzati cars 
that are transparent to the user, such as dealing vith register use versus mmry use or 
caching. Aiother exarple of such an optirization raid be care that naves a value to a 
storage place earlier thanexpected according to the source prograrp hut that does not nat¬ 
ter since that parti cdar mnary location is not needed ary mre. Hanressy exarines the 
tradeoff betveen the optirization of code and the ability to syrhdically debug it[Har79], 
vhile Zellveger both studes the problemaf dehu^ng optirized program and atterpts 
to coufrant one aspect of this prolien[i2el84]. 

Afinal area of research suggested by Mygen vrrk is the generation of true parallel 

1 “A’cMtecture” in this case refers to the evaluati on envirommnt mnus the runtiiM system 



CHAPTER 7 . CONCL US I ONS 


57 


Hie 7.2: Debugger Generati on Systems: Ar e a s to Ex p l o r e 


Separatian of runtim systeminterface 
Characterization of source languages 
Gnerationof SH routines 
Characterization of nachine architectures 
Gnerationof MI routines 
Characterization of runtim system 
Gnerationof ESI routines 
Holding of Qitinhzed Ghde 
Aid tion of Tue Ihrallelism 


debuggers. Athough Mygen’s approach of having knowledge cf nnltipie processing nodes 
hut debugging oriy one node at a tim is suffiient for this initial project in debugger 
generation, future wrkwll probably need to better address parallel debugging issues. 

The suggested areas to explore in further research of debugger generati on system are 
sunniarizedin Hie 7.2. 

Whout question, Mygen not oriy has presented an interesting and viable approach 
to providng debugging support for ndtipie language system, hut has also suggested a 
veal th of interesting research topics to pursue. 



Ap p e ndix A 

SLI Input File Tfe npl ate 


%% iNroTniEroRWEmsaHEiAGmi; 

SGIHRIv'NIAENMB 

(e.g., (II) 

w##% 

your sourcel auguage _nam 

HBlDQRnffiW PAH 

(e.g., /users/tsien/mygen/opal/) 

w##% 

your debugger _1 i br ar j^pat h _nam 

nHjG^nHWniEMEWI r H3irEEAnN3"lib" CRUMIINI' 1 .a": 
(e.g., for "libmf_debug.a", only use "mf_debug") 

w##% 

your _1 i br ar yfil enaii 


/^oftocedures: Wo 


10 
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1. V###%Y 

int initsli (vo i d) 

m= = 

/'8'olfequi res:- 

/$oMdi fies:- 

/'8'aEffect s: Lbes any necessary i ni ti ali zati ons f o r SII 

°/% Ifeturns: li f everythi ng i ni ti ali zed ok; 0 othervi se. 
/'S'oNjte: (If procedure rissing, assumd that there is 

°/% no i ni ti ali zati on necessary f or SII) 

m = 


2. ^t##%[Yor 

int napoc_to_object(char *proc, char *label) 

m = 

/'8'olfequi res: proc is nam user uses to refer to gi ven procedure 
°/% label is nam that conpiler right use to refer to proc 

/$oMdi fies:- 

/$oEflects: 

°/% Ifeturns: —1 i f syntax error i n proc spec 

°/% 0 i f procedure not found 

°/% n > 0, where n =obj ect line corresponding to 

°/% the source code of proc 

m = 


3- Yor 

int nap’ocbegi n to obj ect(c h a r *proc, char *label) 

m = 

/'8'olfequires: proc is nam user uses to refer to gi ven procedure 
°/% label is nam that conpiler right use to refer to proc 

/$oMdi fies:- 

%f)Eflects: 

°/% Ifeturns: —1 i f syntax error i n proc spec 
°/% 0 i f procedure not found 


n >0, where n =obj ect line corresponding to 
the beginning source line of proc 
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m = 

4- W##%[Yor 

i n t nap’ocend to obj ect(c h a r *proc, char *label) 

m = 

/'8'olfequires: proc is nam user uses to refer to gi ven procedure 
Wo label is nam that conpiler right use to refer to proc 

/$oMdi fies:- 

9%Hlects: 

Wo Ifeturns: —1 i f syntax error i n proc spec 
Wo 0 i f procedure not found 

Wo n, where n =object line corresponding to 

Wo the end source line of proc 

Wo -7 0 


5- W##%[Yor 

void trpDecedure(c h a r *proc, char *label) 

m = 

/'8'olfequires: proc is nam user uses to refer to gi ven procedure 
Wo label is nam that conpiler uses to refer to proc 

8$oMdi fies:- 

8'8'oElects: Lbes whatever is necessary to trace proc 

Wo Ifeturns:- 

Wo -8 0 


6- W##%[Yor 

i nt naspourcetoobj ect(i nt srcline) 

Wo = 

8'8'olfequi res: srcline is an integer 

%fMdi fies:- 

/$oEflects: 

Wo Ifeturns: —1 i f there is not source code at line srcline, or 
Wo i f a breakpoint cannot be set at that line. 

Wo n, where n =obj ect line corresponding to 90 

Wo line srcline. 
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m = 

7 . ( m ##%y 

i n t reayhbol s(c h a r *filenam) 

m = 

%Hfeqnires: filenam is the nam of file withsynbols to be read in 
9%Mdi ties:- 

/%Eflects: Loads user programsynbols and/or labels; 

Wo sets global i n t progranstart loc to be address of 100 

Wo where programstarts, i f knowi Sets global 

Wo char useprogranf] to be filenam. 

Wo Ifeturns: li f syrtbols read successfully; 0 otherwise. 

m = 


8- Yor P} 

void prliail)els(c h a r *argl) 

m = 

9%Ifequires: argl is not required, but could be used 

%fMdifies:- 110 

%fEflects: Hints out labels of user programcurrently 1 oaded. 

Wo Ifeturns:- 

Wo = 


9- W##%[Yor P} 

void Jorefcedures(c h a r *argl) 

Wo = 

/$aEfequires: argl is not required, but could be used 

9%Mdi fies:- 

%fEflects: Hints out procedures of user programcurrently 1 oaded. 120 

Wo Ifeturns:- 

Wo = 


10. W##%[Yor P} 

void prsynltbol s(c h a r *argl) 
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/'8'olfequi res: argl is not required, but could be used 
9%Mdi fies:- 

/'8'oHlect s: ftints out synbols of user programcurrently 1 oaded. 

Wo Ifeturns:- 130 

Wo = 


11- W##%[Yor 

void dispfiarn’ce_linetext(c h a r flame) 

Wo = 

/'8'olfequi res: src line is a line of user programor is enpty 
8$oMdi fies: - 

/'8'oEflects: ftints out source code corresponding to line src line 

Wo of user prograrp or, i f srcline is enpty, then 

Wo shov® current 1 ocati on i n programand the source 140 

Wo code corresponding to current location. 

Wo Ifeturns:- 

Wo = 


12. W##%[Yor 

void untrjpr©cedure(c h a r *proc, char *label) 

Wo = 

8'8'olfequires: proc is nam user uses to refer to gi ven procedure 
Wo label is nam that conpiler uses to refer to proc 

9%Mdifies:- 150 

/'8'oEflects: Lbes whatever is necessary to untrace proc 

Wo Ifeturns:- 

Wo = 


13. W##%[Yor ^ 
void prslrifi nfo(v o i d ) 

Wo = 

8'8'olfequires:- 

8$oMdi fies:- 

8'8'oEflect s: print source language infornation relevant to debugging 

Wo Ifeturns:- 


160 
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m = 

14. W##%[ Yor P} 

i n t H’ocessSIIA’gs(i n t argc, char *argv[], c h a r *prognam) 

m = 

/'8'olfequi res: prognam is nam of debugger program 
/$oMdi fies:- 

/'S'EEBect s: ftocesses argumnts, i f any, of a generated debugger. 

°/% Runts a "Usage error:" line to output i f returning 0. 170 

°/% Ifeturns: li f everythi ng ok; 0 otherwise. 

m = 


EXTEPSIWOMfflNES 


MJ\HR(T EXIETSI WOMfflNCg 

(0 <=nunber <=20) 

( m##% iso 

<tiunber> 

Rir each extension comand, specify: 

(1) helpline, including both nam of comand user will type 

and hel p stri ng f or hel p mnu 

(e.g. , "ta Toggle all-solutions.") 

(2) invocation of nam of routine to be called, using argumnts 

argl, arg2, arg3 (rax 3 args) 

(e. g. , "toggle_all_solutions () ;") 

(3) ext e r n reference line 

(e.g., "extern void toggle_all_solutions () ; ") 

EXSMIE 


190 


Extension Gnnand 1 

w##% 
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ta <[i> Toggle all —solutions, n =mx lumber of sol ns 

w##% 

t oggl e_al Is ol ut i ons (ar gl); 

W##% 200 

extern vo i _dl_to^glfeoiis(); 



Ap p e n d i x B 

MAI Input File Tib npl ate 

Wo INOTHIEKIMrKIlTSm’AmTEniUE 

TfflffiT Am TEEIUE ME 
(e.g., CM) 

w##% 

your archi tecturenarm 

hhiiir n rowPAH 

(e.g., /users/tsien/imygen/on/) 

( m##% 10 

your debugger _1 i br ar j^pat h _nam 

IIHjGminHWniENOTWmiirEEAIN3"lib" CR r IRAIIN3".a": 

(e.g., for "libmf_debug.a", only use "mf_debug") 

w##% 

your _1 i br ar yfil enaii 

AILHL MMERCF FKJIBSIN3MIIS INTMETAmTECIUE 

("1" for a uni processor) 

( m##% 20 

your nurtber 


65 
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□SIEEDNMfRCF FKHBSIN3N3IB INTMETMHTECIUE 
(IISIEEDNJ\IIR<=A1JU^NJ\I^ "1" f or a uniprocessor) 

w##% 

your nurtber 


/^oftocedures: Wo 

< mmmwo 30 


1. V###%Y 
i n t iniit(v o i d ) 

Wo = 

/'8'olfequires:- 

/$oMdi fies:- 

/^oBfects: Lbes any necessary i ni ti ali zati ons f o r MI 

Wo Ifeturns: li f i ni ti ali zati on successful; 0 otherwise. 


40 

2 . ( m ##%y 

i n t progralmaded(v o i d ) 

Wo = 

/'8'olfequires:- 

9%Mdi fies:- 

/^oEBects: 

Wo Ifeturns: 1 i f programis loaded 
Wo 0 i f programis not loaded 


50 

3- W##%[Yor 

i nt Install Mchi neQeakpoi nt(i nt addr) 

Wo = 

/'8'olfequi res: addr is a valid code address of the current 
Wo programwhere a breakpoint can be set 

/$oMdifies: (object code) 
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/'8'oElect s: Installs a breakpoint at addr such that when 

Wo programexecution reaches addr, it halts 

Wo Ifeturns: Qiginal instruction (i nt ) being repl aced by breakpoint, 
Wo to be passed to Ihi nstall Mchi neBeakpoi nt. Ifeturns 

Wo an integer <0 i f did not install correctly. 

m = 


4. V###%Y 

void contijmegranflv o i d ) 

m = 

/'8'olfequires:- 

9%Mdi fies:- 

/'8'oElect s: If programis running, continues running it. 

Wo Qhervise prints a mssage to user that program 

Wo should be started first. 

Wo Ifeturns:- 


5- W##%[Yor 

i n t Ihi nstall Mchi neBeakpoi nt(i nt addr, i nitastjrhigfi on) 

Wo = 

/'8'olfequires: addr is avalidcode address of the current 

Wo programwhere a breakpoint can be renmved; 

Wo orig _i nstructi on i s identical to that returned by 

Wo Inst all Mchi neBeakpoi nt 

%f)Mdifies: (object code) 

/$oEflects: Ihinstalls a breakpoint at addr such that when 

Wo programexecuti on reaches addr, it no longer halts 

Wo due to this breakpoint. Qiginal instruction is 

Wo reinstated. 

Wo Ifeturns: i nt n: n=0 i f worked cor recti y; n<£) i f did not work 
Wo = 


6- 9$£##%[Yor 

i n t Set Mchi neBocBeakpoi nt (c h a r *proc, i n t n, i_aa)t trace 
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m = 

/'S'olfequi res: proc is nam user uses to refer to a procedure on which 
Wo a breakpoint is to be added 

Wo nis the code address where this procedure starts 

/$oMdifies: (object code) 

/^oEflects: Aids proc to list of procedure breakpoints by calling 

Wo i nt addtoprocbreakpt _list(c ha r *proc, i nt addr, 

Wo i nt tracen). (1 i f good; Oi f bad) 

Wo (in SKEL) and adds corresponding nachine address 100 

Wo breakpoint(s) fromlist by calling (in SHL ) 

Wo i nt addtomchine breakpt _list(i nt addr). 

Wo (1 i f good; 0 i f bad) 

Wo Ifeturns: li f set successfully; 0 otherwise 
Wo = 


7. ^t##%[Yor 

i n t QearMchineH’ocB’eakpoint(c h a r *proc, i n t n) 

Wo = 

/'8'olfequi res: proc is nam user uses to refer to a procedure on which 110 

Wo there is a breakpoint to be rernved. 

Wo nis the code address where the procedure starts 

/$oMdifies: (object code) 

9%Hlects: Ifemves proc fromlist of procedure breakpoints by calling 

Wo i n t remvefromproc breakpt _list(c h a r *proc, i n t addr) 

Wo (1 i f good; Oi f bad returned) 

Wo (in SHL) and rerroves corresponding nachine address 

Wo breakpoints fromlist by calling (in SHL ) 

Wo i nt rerrovefrom mchi ne breakpt list (i nt addr) 

Wo (1 i f good; Oi f bad returned) 

Wo Ifeturns: li f successful; 0 otherwise 


8. V###%Y 

i n t repcbgranlic h a r *filenam) 
Wo 


120 
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/'8'offequi res: filenam is the nans of file to be read in 
/'S'oMdi fies: (inchine state) 

/'8'oEfiects: Loads user program loads the code into the code 

Wo minry. Set flags such that program loaded)) w 11 

Wo r e t ur n true. Ifeinitialize mnmry, etc. 

Wo Ifeturns: li f programread successfully, 0 otherwise 

m = 


9. W##%[Yor P} 

void priegi stercontent s(c h a r *argl, char *arg2) 

m = 

/'8'offequi res: argl is possibly an environnant 
9%Mdi fies:- 

8'8'offiects: Hints the contents of the nachine registers; 

Wo If envis given, only prints that envi ronnant 

Wo Ifeturns:- 

Wo = 


10 . V###%Y 

void _ptn>gran|ic h a r *al) 

Wo = 

z^olfequires: argl i s enpty or is a li ne nunber at whi ch to begi n 

Wo execut i on 

/$oMdi fies:- 

8'8'offiects: Ifeports that user programis already running (and 

Wo suspended) or e lse begins to run the program 

Wo Ifeturns:- 

Wo = 


11- W##%[Yor P} 

v o i d_sd@p(c h a r *argl, char *arg2) 

Wo = 

8'8'offequires: argl is enpty or the nunber of steps user rants to step. 

Wo arg2 i s enpty or the 1 ocati on f romvhich to begi n steppi ng 


/$oMdi fies: 
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/^Effects: Executes argl steps of user program beginning at 

Wo 1 ocati on arg2. 

Wo Efeturns:- 

Wo = 


12. ^t##%[Yor P} 
v o i d_H(g_step(c h a r *argl) 

Wo = 

/'8'oEfequires: argl i s enpty or the 1 ocati on fromwhi ch to begi n steppi ng 170 

9%Mdi ties:- 

/^Effects: Executes a process/procedure of user program beginning at 

Wo 1 ocati on argl. 

Wo Efeturns:- 


13. V###%Y 

void rasKthine(v o i d ) 

Wo = 

9%Efequires:- 180 

/'S'oMdi fies: rachine state 

/^Effects: Efesets the rachine state, sets running to false (0) 

Wo = 


14. W##%[Yor P} 
void prrarit _info(v o i d ) 

Wo = 

/$oEfequires:- 

9%Mdi ties:- 

/'S'EEBects: Flints out i nf or rati on about user program debugger 190 

Wo status, etc. 

Wo Efeturns:- 

Wo = 


15. W##%[Yor P} 

i n t EE ocessMlA’gs(i n t argc, char *argv[], c h a r *prognam) 
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m = 

/'8'olfequi res: prognam is nans of debugger program 
9%Mdi fies:- 

/^oEflects: ftocesses argunants, i f any, of a generated debugger. 

Wo Runts a "Usage error:" line to output i f returning 0. 

Wo Ifeturns: li f everythi ng ok; 0 otherwise. 

m = 


16. W##%[Yor P} 
i n t changje>de(i n t argl) 

m = 

/'8'olfequires: argl is aninteger specifying the newnode to be 

Wo debugged Is al ready checked for <=nax avai 1 abl e 

Wo and >0 

/'S'oMdi fies: mchine state 

/^oEflects: Lbes the necessary internal state changes to debug 

Wo node nunber argl 

Wo Ifeturns: li f everythi ng ok; 0 otherwise. 

Wo = 


17. W##%[Yor P} 
i n t reshuaber nodes (i n t argl) 

Wo = 

/'8'olfequires: argl is aninteger specifying the newdesired nunber 

Wo of processi ng nodes. Is al ready checked f o r <=nax 

Wo and >0 

/'S'oMdi fies: mchine state 

/'8'oEflect s: Lbes the necessary internal state changes to alter 

Wo desired nunber of nodes available to argl 

Wo Ifeturns: li f everythi ng ok; 0 otherwise. 

Wo = 


EXHPSIQiaMfflNES 


230 


200 


210 


220 



APPENDIX B. MAI I NPUT FI LE TEMPLATE 


72 


NJ\ffiR(T EXE^IWCOMNS 
(0 <=nunber <=20) 

w##% 

<nurtber> 

Rir each extensi on conmnd, specify: 

(1) helpline, including both nan® of conrand user vill type 

and hel p stri ng f or hel p mnu 

(e.g. , "ta Toggle all-solutions.") 

(2) invocation of nan® of routine to be called, using argunsnts 

argl, arg2, arg3 (iax 3 args) 

(e. g. , "toggle_all_solutions() ;") 

(3) extern reference line 

(e.g., "extern void toggle_all_solutions () ; ") 

EXMIE 

Extensi on Gmmmd 1 250 

w##% 

ta <Jr> Toggle all—solutions, n =ibi nurtber of sol ns 

w##% 

t oggl e_al Is ol ut i ons (ar gl); 

w##% 

extern vo i _dl_to^gtfeons(); 


240 



Ap p e n d i x C 

Sanpl e OMVi rt ual Ml chi ne 1VM 
I nput Fi 1 e 


Wo MI INOTHIEKIlT«ErAmTEniUE(MVIRiraLMtHKE 

TfflffiT AlH TEEIUE ME 

w##% 

(M 

hhiiir n rowPAH 

W##% 

/users/tsien/ imygen/ on/ 

10 

IIHjGminHWniENOTWlHIirLEA3N3"lib" CRTRAIIN3" .a": 

W##% 

ng nad 

A3LHL NMERCF FKJIBSIN3MIIS INTMETAmTECIUE 

w##% 

1 
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□SIEEDNMfRCF FKHBSIN3N3IB INTMET4EmTECIUE 

( m ##% 20 

i 


/$oBocedures: Wo 


1. V###%Y 

i n t imit(v o i d ) 

2 . ( m##% y 

i n t progrdmaded(v o i d ) 

3 . ( m##% y 

i nt InstallMchineBeakpoint(i nt addr) 

4 . ( m##% y 

void contijmegranliv o i d ) 

5 . ( m##% y 

i n t Hi nstal 1 Mchi neBeakpoi nt(i nt addr, i n itastaringion) 

6 . ( m##% y 

i n t SetMchi neBocBeakpoi nt (c h a r *proc, i n t n, i_cm)t trace 

7. ( m##% y 

i n t Q ear Mchi neBocBeakpoi nt(c h a r *proc, i n t n) 

s. ( m##% y 

i n t refriigran^c h a r *filenam) 

9. 50 

void priegi ster content s(c h a r *argl, char *arg2) 


30 


10. V###%Y 
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void jprogranlic h a r *al) 


11. V###%Y 

v o i d_sdep(c h a r *argl, char *arg2) 

12 . ( m ##%y 

v o i d_bfl(g_step(c h a r *argl) 


13. V###%Y 

void raaEthine(v o i d ) 


14. V###%Y 

void pnrait _i nfo(v o i d ) 


15. V###%Y 

i n t H’ocessMIA’gs(i n t argc, char *argv[] , c h a r *prognam) 

70 

16. 

i n t changede(i n t argl) 

17. 

i n t reshuaber nodes(i n t argl) 


EaE^IWCOMNEB 


NMJRCF EXIENSCNCIMfflNEB so 

W##% 

12 


Bdension Ghnmmd 1 

w##% 

ta Toggle all—solutions. 

w##% 

t oggl e_al l_s ol ut i ons (); 


60 
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extern vo i_dljbofegleoiis(); 

Extensi on Ghnrand 2 

w##% 

tb Toggle breadth—first search 

w##% 

t oggl e_br e adt h fir s t (); 

w##% 

extern vo i 14 efcdgjjl (first (); 

Extensi on Ghnrand 3 

w##% 

tq Toggle quiet raide. 

w##% 

toggl e_qni et_raide(); 

w##% 

extern vo i ttoggldeQ; 

Extensi on Gbraand 4 

w##% 

tp T>ggle process trace. 

w##% 

t oggl e_pr oces s _t r ace (); 

w##% 

extern vo i j4ofcegglferace(); 

Extensi on Ghnrand 5 

w##% 

ti 


90 


100 


110 


120 


T)ggle instruction trace. 
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toggl e_i nstructi ontraceQ; 

w##% 

extern vo i ihstogglfeontraceQ; 

Bdensi on Gninand 6 

w##% 

td Toggle synbolic reg display. 

w##% 

toggl e syrtboli c _di spl ay(); 

w##% 

extern vo i _s|rnbo^gfce_di spl ay(); 

Bdensi on Gninand 7 

w##% 

p>c ftint code from<n>to <rtj> 

w##% 

pri nt_code(argl, arg2); 

w##% 

extern vo ic«He^jnt 

Bdensi on Gninand 8 

w##% 

ph ftint heap from<ti>to <ji> 

w##% 

pri nt_heap(argl, arg2); 

w##% 

extern vo Bndip(p)’int 

Bdensi on Gninand 9 


130 


140 


150 


pm 


ftint rassage (detailed contents of Mreg). 
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W##% 

print rmssage _info(argl, arg2); 

w##% 

extern vo indsj^fenti nfo(); 

Extension Ghnrand 10 

w##% 

pp Flint process (detai 1 ed contents of Preg). 

w##% 

print_process_info(argl, arg2); 

w##% 

extern vo ijiri>cf®$ntnfo(); 

Extension Ghnrand 11 

w##% 

pq Flint nsssage queue. 

w##% 

pri nt queue cont ent s (); 

w##% 

extern vo ^qituprjcmtntentsQ; 

Extension Ghnrand 12 

w##% 

pt Flint process tree. 

w##% 

pri nt_process_tree(); 

w##% 

extern vo iprf)C{®snltree(); 


78 


160 


170 


180 
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